This disclosure relates generally to transactional aborts in a multiprocessor computing environment with transactional memory, and more specifically to inducing transactional aborts in one or more other processing threads by the action of a first processing thread.
The number of central processing unit (CPU) cores on a chip and the number of CPU cores connected to a shared memory continues to grow significantly to support growing workload capacity demand. The increasing number of CPUs cooperating to process the same workloads puts a significant burden on software scalability; for example, shared queues or data-structures protected by traditional semaphores become hot spots and lead to sub-linear n-way scaling curves. Traditionally this has been countered by implementing finer-grained locking in software, and with lower latency/higher bandwidth interconnects in hardware. Implementing fine-grained locking to improve software scalability can be very complicated and error-prone, and at today's CPU frequencies, the latencies of hardware interconnects are limited by the physical dimension of the chips and systems, and by the speed of light.
Implementations of hardware Transactional Memory (HTM, or in this discussion simply TM) have been introduced, wherein a group of instructions called a transaction operate in an atomic manner on a data structure in memory as viewed by other central processing units (CPUs) and the I/O subsystem (atomic operation is also known as “block concurrent” or “serialized” in other literature). The transaction executes optimistically without obtaining a lock, but may need to abort and retry the transaction execution if an operation, of the executing transaction, on a memory location conflicts with another operation on the same memory location. Previously, software transactional memory implementations have been proposed to support software Transactional Memory (TM). However, hardware TM can provide improved performance aspects and ease of use over software TM.
U.S. Patent Application Publication No. US2010/0162247, titled “Methods and Systems for Transactional Nested Parallelism”, published Jun. 24, 2010, at ¶91[0087]-[0092] teaches:                In one embodiment, for a transactional memory system that supports transactional nested parallelism, any thread from a same group of threads is able to trigger an abort.        In one embodiment, a child thread writes a specific value to [an abort flag] when it is going to abort. In one embodiment, [the abort flag] is readable by all threads in a same group including the parent transaction. If any thread in the same group aborts, all the threads of the same group are also going to abort. In one embodiment, the main transaction aborts if any thread created in response to the main transaction (including all the descendents thereof) aborts.        In one embodiment, checkpoint information for each child tread [sic] is saved separately. If any team member triggers an abort, [the abort flag] is set visible to all threads in the team. In one embodiment, [the abort flag] is stored in [a descriptor] or in descriptor [sic] associated with a parent transaction.        In one embodiment, a team member examines [the abort flag] periodically. In one embodiment, a team member examines [the abort flag] during some “poll points” inserted by a compiler. In one embodiment, a team member examines [the abort flag] during runtime at a loop-back edge. A child thread restores the checkpoint and proceeds directly to the join point if [the abort flag] is set.        In one embodiment, a team member examines [the abort flag] when the execution has completed and the child thread is ready to join.        In one embodiment, if a team member determines that [the abort flag] is set, a team member follows the same procedure as the thread that triggers the abort. In one embodiment, the roll-back operation of a team member is performed by the team member itself after the team member detects that [the abort flag] is set. In one embodiment, roll back operations are performed by a parent transaction that only examines [the abort flag] after all child threads reach the join point.        
U.S. Patent No. US2012/0005530, titled “System and Method for Communication Between Concurrent Transactions Using Transaction Communicator Objects”, issued Jan. 5, 2012, teaches:                Transactional memory implementations may be extended to include special transaction communicator objects through which concurrent transactions can communicate. Changes by a first transaction to a communicator may be visible to concurrent transactions before the first transaction commits. Although isolation of transactions may be compromised by such communication, the effects of this compromise may be limited by tracking dependencies among transactions, and preventing any transaction from committing unless every transaction whose changes it has observed also commits. For example, mutually dependent or cyclically dependent transactions may commit or abort together. Transactions that do not communicate with each other may remain isolated. The system may provide a communicator-isolating transaction that ensures isolation even for accesses to communicators, which may be implemented using nesting transactions. True (e.g., read-after-write) dependencies, ordering (e.g., write-after-write) dependencies, and/or anti-dependencies (e.g., write-after-read dependencies) may be tracked, and a resulting dependency graph may be perused by the commit protocol.        